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(57) A personal device is to be connected to a ter- 
minal and being equipped with a computerized method 
for establishing a trustworthy connection between a us- 
er via said device and the terminal which is connected 
to and authenticatable by at least one server which is 
authenticatable by the device. In the case the device is 
coupled to the terminal, a first authenticatton step is in- 
itiatable during which the terminal authenticates itself to 
the server, upon success of which, between the server 
and the terminal, a first authenticated trusted connection 
Is established. Subsequently a second authentication 
step is initiatable during which via the established first 
authenticated trusted connection the server authenti- 
cates itself to the device, upon success of which, be- 
tween the server and the device, a second authenticat- 
ed trusted connection is established. Subsequently at 
the device during a first messaging step, from the server 
via the established second authenticated trusted con- 
nection, a terminal authenticity message is receivable 
confirming the established authenticity of the terminal. 
Subsequently during a second messaging step an au- 
thenticity output message is communlcatable from the 
device to the user via a device output of the device and/ 
or via a terminal output of the terminal. 



f 1 ' 



Si 5, 



.,11.: 



; 1 i ; I 



' : I * 

! ' ! ' 

i ! ! i 



1 



■: ax: 

J AH 



Q. 
UJ 



Printed by Jowe. 75001 RARIS (FR) 



1 



EP 1 026 641 A1 



2 



Description . - 

[0001] The invention relates to situations where un- 
trusted terminals .are used to access a computer sys- 
tem. More particularly,' it relates to public untrusted ter- 5 
minals which are connected via a network to a computer 
system and the authentication of such public untrusted 
terminals. 

TECHNICAL FIELD AND BACKGROUND OF THE io 
INVENTION ... 

[0002] Automatic teller machines (ATM) and'lntemet 
kiosks, are: typical examples of public untrusted termi- - 
nats which. a re used to access computer systems. A typ- is 
ical system is illustrated in Figure 1. A user 1 is conskj- ' 
ered, withdrawing money from an ATM 6 using a bank 
card 2. In all existing systems, users 1 have to enter a 
personal identification number (PIN) or pass-phrase in 
order to reliably authenticate themselves to the bank. 20 
But there is- no way for the user 1 to authenticate the 
bank., respectively the ATM 6. There have been inci- , 
dents where thieves set up fake ATMs and successfully 
stole PINs and magnetic stripe inlonmation from unsus- 
pecting users. : ! ... . 2S 
[0003] The same fake-ternninal problem occurs in 
many other settings as considered in the folk>wing. 
[0004] ATMs and pointof-sale terminals: In both see-, 
nartos, every user 1 is registered with a specific server ■ 
5 (e.g., a credit-card issuer); All transactrans of the user 30 
1 are eventually authorized by the servers. Servers 5 
can typically identify and authenticate legal terminals 6.: 
A typical attack scenario Is when the attacker would set < 
up an illegal tenminal 6 which warts tor the user 1 to.type . l 
in the PI Nrcode. ; read any necessary information from 3s 
the card 2. and then refuse service; for example by dis- ■■■ 
playing a "terminal out of order." messaged Unsuspecting . 
users 1 will simply move on to a different terminal 6. The , , 
attacker can later use the stolen Information, at a legal r _ 
terminal s., .■ . . . . - 40 
[0005] Public Internet kiosks: Short-term access to 
the Intemetfrom public terminals is an increasingly conr^ 
mon.featureJn malls^ airports;, the so-called "Internet, 
caf^s," and other public places. There is little risk for usr 
ers who merely want to "surf" the. web from these termi- 
nats. .But people can,.^ and do,. perform more securltyr ; 
sensitive .transactions such as accessing their personal 
or business computer systems, making payments etc. 
from public Internet kiosks. This scenario differs from 
the previous ones in some respects: - i • ■ 

• the user 1 may access several servers 5 frohn the -X'-" , 
same terminal 6, and - ^ , 

• the types of private information which needs to be ss 
protected may not be fixed, or even known a priori.. 

[0006] A similar scenario arises in the case of virtual 



mall kiosks. Virtual mall kiosks allow prospective cus- 
tomers to browse through and purchase the wares ad- 
vertised by shop-keepers in the virtual mall. Functional- 
ly, this scenario is similar to public Internet kiosks. 
[0007] In specific settings, such as ATMs that use bi- 
ometrics instead of passwords to authenticate, the fake- 
terminal problem can be avoided. However, the general 
problem remains. A solution to this general problem 
mustilake into account different scenarios where the re- 
sources available to a user may be different: a user may 
have a trusted personal device with its own display or 
may have only a standard integrated chip card (e.g. a 
smartcard): with no display attached, or, in the simplest 
and most common case,- noay not have any persorial 
trusted device at all. ' ' 

[0008] ■ The article "TrustlngTrrroblle user devices and 
security modules" in Computer, innovative technology' 
for computer prof ess ionaly, Feb.-1997, IEEE Computer 
Society, pp 61-67 a simple protocol is described, iwhere 
a user can authenticate a user device with display. 

OBJECT AND ADVANTAGES OF THE INVENTION 

[0009]' It is an object of the present invention to pro- 
vide a scheme to solve the problems associated with 
untrusted pub lie terminals. 

[0010] 'It is another object of the present invention to 
provkJe a scheme for a user to authenticate a public ter- 
minal before using It to process sec utity-sensitive Infor- 
mation. (- ' ; V 
[001 1] These and other objects are accomplished by 
a device, terminal,. server, communication system, and' 
a method, as claimed in claims 1 - 41 . 
[0012] The personal device according to claim 1 of- 
fers the advantage that the user can authenticate an un- 
knovm and hence ex ante untrusted terminal and there- 
by find out- whether the terminal can be trusted or not 
[0013] , When the devk^e comprises stored predeter- 
mined authentication informatk)n which is communicat- 
ableto the terminal, the device need not have an output 
means for outputting the authenticity output message. 
The device hereby takes advantage of the output capa- 
bility of the terminal and the trusted pathe that has been 
established before. 

[0014] ■ Using a third authentication step for the per^- 
sonal device to authenticate itself to the terminal brings 
in the advantage that not only the device can trust the 
server and via.the server the terminal, but^lsd the ter- 
minal can trust the device. Thus, also the temiinal has 
the possibility to detect a fraudulent device and to inter- 
rupt secutity-sensitive applications upon detection of il- 
legal personaldevices. ' ^ . r ' - ' 
[001 5] Using bidirectional authentication steps is ad- 
vantageous.- since then bothe parties in the authentica- 
tion upon success trust each other which results in a 
fully bidiractional trusted channel. Security-sensitive in- 
formation can be exhchanged hence, also bldirectional- 
ly. The third authentication step may then be renounced. 
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[0016] Requesting the user to authenticate himself 
again is advantageous in that also the device sees 
whether rt can trust the user. Thus, also the device has 
the possibility to detect a fraudulent user and to interrupt 
secutity-sensitive applications upon detection of illegal s 
users. 

[001.7] It prooves of great practical advantage when 
the authenticity output message comprises visible and/ 
or audible and/or tactile information, because this Is hu- 
man-interface-readable information which renders rec- io 
ognition of a trusted terminal uncomplicated and fast. 
[0018] If the authenticity output message comprises 
at least one value for lookup in a table.stored in the ter- 
minal; the personal device needs less memory space 
since a simple reference to a place in the lookup table i5 
suffices to identify the correct authenticity output infor- - 
mation. : 
[0019] A scenario, where the authenticity output mes- 
sage is communicatable to the terrninal by the server, 
the authenticity output message preferably having been 20 
transmitted to the server by the user, refers to a situation 
when the personal device not even Ms writable; by the 
user This opens the invention to the field of prefabricat- 
ed, not-amendable personal devices, such as prepro- 
grammed or prewritten smartcards or magnetic cards. 
[0020] Higher security can be achieved, wtien the au- 
thenticity output message is communicatable to the ter-' 
minal by the server upon successful.authentication of 
the device to the server, because the authenticity output 
message is safe in the server, as long as no authenti- .30 
cation has taken place. No attacker can hence some- : / 
how get the authenticity output message out of. the de- : 
vice. 1 . ■ ~ 

[0021] Using only part of the authenticity output mes- * 
sage to be presented to the user, the achievable security 3S 
Is again higher, because the user can use the same au- . 
thenticity oirtput message. several times without risking" 
that an attacker somehow rrtanages to spy out the out- > 
put message and use it the next time to cheat on the 
user by using a fake terminal piret'ending to be a legal 40 
terminal. . , , ^ , . ■ • . 

SUMMARY OF THE I r^fVENTION - ' . 

[0022] ?The inveption is related to a system which al-. .45 
lows a user to autheticate unknown terminals: The user 
can hereby detect if a terminal he wants to use is a fake 
terminal or if. iti is a .legal temiinal and can be trUsted. 0 
Only trusted terminals should be used to perform secu- 
rity-sensitive actions via the terminal. The invention us- 
es a frrst authentication step wherein the term irvai au- 
thenticates itself to a server The authentication is either 
initiated simply by coupling the personal! device to the 
terminal, or by sorhe additional action performed. by the 
user The user can e.g. additionally press one or more ss 
buttons or keys on the terminal or- on the personal de- 
vice, wherever such input means are present. For au- ; 
thentication any known authentication system can be 



used, e.g. using a private-public key sytstem. Depend- 
ing on whether the personal device has an own output 
means, such as a loudspeaker or a screen, the final 
message, whether the terminal can be trusted or not, 
can be output on the personal device or on the terminal 
itself. Since the user trusts his personal device^ this 
message should come from the device itself. In the 
case, the device has no own output means, this mes- 
sage can hence be originating in the device and be from 
there transmitted to the terminal, which outputs it.'The 
user can herefor input authenlicaition information into 
his personal device which can then be fully or partiaify 
transmitted to the terminal. In the end, the terminal may 
use the transmitted information to give out the authen- 
ticity output message. After the first authentication step 
follows a second authentication step, wherein the server 
authenticates itself to the personal device, if there is 
one. Upon success of both authentication steps, the au- 
thenticity output message can be given to the user If 
the personal device has no writing-capacity, the authen- 
tication information, also called authentication vector, 
can be transferred by the user via a trusted channel to 
the server Upon successfullauttientications, the server 
can then output some message to the terminal to make 
it output the authentkiity output message. The message 
from the server to the terminal can therefor be the au- 
thenticity output message itself, part of it, or any other 
kind of message that effects the issuance of the authen- 
ticity' output message to the user In \he case, the user 
has no^own personal device, also the method ca be used 
to transmit to the server the authenticaton vector before 
to approach a terrninal. The uiser has agreed with the 
server on one or moce tuples of challenge-resporise-au- 
thenticatioh : vector type.' i The authentication is per-f 
formed via the cha[lenge^espon$e principle and upon' 
successful! authentication, the server firmlly issues or- 
has issued the authenticity output rnessage via the ter- 
minal. The second messaiging step, i.e. the butput'of the 
authenticity output- message Is preceded by a first mes- 
saging step v^ich comprises the issuance of a message 
from the server- The message of the firet nriessaging 
step tells that the terrninal can be trusted.^ ' ' < 
[0023] In any of the embodiments, the messages that 
are transmitted, h^ed 'not be transmitted in full. It may 
suffice to send 6nly part of the message or some pointer 
to it and ^to have the^finat authenticity output message 
or the terminal authenticity message be looked up in a 
lookup table. , r ., . • - ■' 

DESCRIPTION OF THE DRAWINGS r 

[0024]'- Examples of the invention are depicted in the 
drawings and described in detail below by way of exam- 
ple. It is shown in 

Fig. l an arrangement with a'device. a terminal and 
a server. 



5 



EP 1 026 641 A1 



6 



Fig. 2 a time scheme of a first metlnod for establish- 
ing a trustworthy connection,.- 

Fig. 3 a time scheme of a second method for estab- 
lishing a trustworthy connection, 

Fig. 4 a time scheme of a third method for estab- 
lishing a trustworthy connection. . 

Fig. 5 a time scheme of a fourth method for estab- 
lishing a trustworthy connection. 

[0025] All the figures are for sake of clarity not shown 
in real dimensions, nor are the relations between the di- 
mensions shown in a realistic scale. 

DETAILED DESCRIPTION OF THE INVENTION 

[0026] In the fol towing, general scheme of the present 
invention and various exemplary embodiments thereof 
are described. , , 

[0027] A typical system in which the present invention 
can be used is illustrated in Figure 1 . The user 1 access- 
es a server system 5, hereinafter referred to as server 
5, from a public untrusted terminal 6. This terminal 6 has 
a terminal output device 3, such as a screen or the tike 
via which it communicates with the user 1 . This terminal , 
output device 3 has also means for the user 1 to com- ■ 
municate with the termir^al 6, e g. a keyboard. The ter- 
minal 6, respectively terminal: output device 3 is con- 
nected to the server 5 via a network 4, which in its sim^ 
plest form can be a direct line. For the purpose of ac- 
cessing the server 5, the user 1 has an account on the 
server 5 whk:h he trusts to correctly authenticate a pub- 
lic terminal 6. Public terminals are tamper-resistant but 
an attacker can easily replace a legal terminal 6 with a 
fake terminal or install a new fakei terminalin a plausible 
location. The servers knows about legal terminals 6 and 
can authenticate them. Infomnatbn necessary fbr a user 
1 to authenticate the server 5 and, where necessary, in- 
formation needed for. the sen/er 5 to authenticate the 
user 1 , is set up duririg known user registration or other 
initialisation steps (e.g.; :agreeing on a shared key). 
Once an entity authenticates another, a confkjential, au- 
thenticated channel is established. as j a result. ,ln other 
words, an attacker cannot hijack an authenticated chan- 
nel resulting from the authentication procedure. The 
symbols U, T, and S, are herein used to identify the user 
1 , the terminal 6, and the server 5, respectively. When 
the user 1 has a trusted personal device 2, e.g. a smart- 
cardi a handheki phone or amagnetic card, it is denoted 
by D. ■ - , ... . ■ ,. ■ 

[0028] The authenticat»n steps mentioned above are 
implemented using authentication protocols. There are 
various well-known authenticaticKi protocols for per- 
forming both one-way and two-way. authentication sufch 
as Secure Sockets Layer (SSL), KryptoKnight, and Ker- 
beros. Details of SSL are described by Alan O. Freier, 



Philip Kariton, and Paul C. Kocher in "The SSL protocol: 
Version 3.0. Internet Draft. 1996. KryptoKnight is ad- 
dressed by R. Bird, I. Gopal, A. Herzberg, P. Janson. S. 
Kutten, R. Molva, and M. Yung in "Systematic design of 

5 a family of attack- resistant authentication protocols", 
IEEE Journal on Selected Areas in Communications. 
Vol. 11, No. 5. pp. 679-693, June 1993, for example. 
Kerbs ros is described by John T Kohl and B. Clifford 
Neuman in "The Kerberos network authentication serv- 

10 ice (VS)". Internet Request for Comment RFC 1510, 
1993:'. 

[0029] The solutbns herein proposed assume the use 
of a suitable authentication protocol, which can be one 
of the above-mentioned protocols, or any other protocol 

15 that serves a similar purpose. . ; 

[0030] The server 5 may be replicated, thereby avoid- 
ing it f ronri becoming a bottleneck. All copies of the serv- 
er 5 need to be aware of the up-to-date set of legal ter- 
minals 6 and the information necessary to authenticate 

20 them. There inay also be several servers 5; each re- 
sponsible for a separate domain. In this case, it is as- 
sumed that the necessary infrastructure, e.g. a pubiic- 
key.infrastructure, for the servers 5 to authenticate each 
other exists. . In either case, the' number of the terminals 

25 6 is f ikety to be several orders of magnitude higher than 
the number of the servers: 5. ■ . ■ 

Case 1: Personal device with bullt-ln output 
capability.' 

[0031] First is ccMisidered the scenario where the user 
1 has a full-fledged trusted personal device 2 with its 
own output channel, such as. a screen of a'handheld 
phone The terminal 6 cannot access &ie device output 
channel. Consequently, the user 1 can be sure' that any 
tnformatbn is communicated to him via this output chan- 
nel does in fact originate from his trusted personal de- 
vice 2 An other words^ there is a. trusted path cO between 
the tmsted personal device. 2 and the user I j(Stla). 

40 When the user 1 (U) walks up to an untrusted terminal 
6 (T), he couples his device 2 (D) to the terminal 6 (T) 
by some means, e.g., infrared link, physical connection 
(St1b,> St1c), and a communication is performed.: The 
corresponding message flow is schematically illustrated 

4S in Figure 2; - C , ; . : 

[0032] First, a first authentication step A I is performed 
during which the terminal 6 authenticates itself to the 
servers. '■>('■ ■ . ' : 

so Tt ,t u ^ D: (Stid) The user U requests the device D 
to authenticate the terminal 6 (T) it is attached to, 
e.g., by clicking on a button on D's display.- 

2. D T; (St 2) The device D requests T to authen- 
55 ..: ticate itself to the server S. 

3. T -> S: (St3a) T runs a one-way authenticatron 
protocol to the server S. If this succeeds, the server 
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S knows that rt has an authenticated channel S-T 
to T. This authenticated channel S-T is established 
as a tirst authenticated trusted connection cl (St3b). 
The server 5 hence trusts the ternninat 6. 

Then a second authentication step A II is per- 5 
tornned making use of the first authenticated trusted 
connection c1. 

4. S -> D: (St4a) The server S runs a one-way au- 
thentication protocol to the device D via the first au- io 
thenticated trusted connection cl . If this succeeds, 
the device D knows that it has an authenticated 
channel S-D to the server Sj- which is tunneled 
through S-T. This authenticated channel StD is es- 
tablished as a second authenticated trusted con- 
nectton c2 (St4b). 

As next step a first messaging step M I follows. 
The terminal sends a session key 'key' to the server 
5 (St 4c). This key can then be used by the server S 
and the terminal T to exchange inforrnation. Since. 20 
the server trusts the terminal it, can accept the key 
and use it. Using this session key enhances secutity. 
since an attacker- trying to spy on the exchanged 
information, respectively modify it inbetween has ' 
neither a chance to read the exchanged information S5 
nor to modify it without the modification being de- 
tected. Using a session key, i.e. a new key for every 
new sesston, which is the uninterrupted use of the 
described system in exactly one configuratkih, in-, 
creases security again, since even a key once spied 30 
out by an attacker is useless for the next sessjoh. . 



5. S D: The server & sends a . message to the : 
effect "T is authentic" via:S-D. TJiis message is a: ' 
terminal autfrenticityifnessage m, which arrives at . '35 
the devbe 2 via the terminals (St5a). In additiOT, 
the server S here sends additional infomriation, ' 
such as the session key . 'key', or one-timo' certifi-. . 
cates, thatare used by the device D and T for a third . . 
authetlcation step A 111. In this step, an authenticar .40 
Xiori protocol is run between the device; D and T r 
(StSb) and upon success: of the authentication a se- ^ 
cure channel D-T. is . constructed between them- ' 
selves (St5c). This authenticated channel D-T is es- ' 
tabllshed as a third authenticated trusted connec- "ts 
-tion c3'(St5c). : 

6. D U: Next folbws a second messaging step M . 
II during which the device D displays a message to 
the effect .T is authentic according to S' totho user 
U. This message is called the authenticity output 
message m^. The appearing authenticity output 
message tells the user U that he can trust the 
terminal 6. - ^ 

. • 55 

7. D U: In scenarios where the user U has to au- 
thenticate to the server S, it can be done in a sep- 
arate phase following the above exchange. For that. 
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during a fourth authentication step A IV the device 
2 may request the user 1 to autheticate himself to 
the device 2 (St7). 

8. U -J. D: The user 1 answers the request by en- 
tering a piece of information which is suited to au- 
thenticate the user 1 as legal user. This piece of in- 
formation is e.g. a personal identity number PIN or 
a pass phrase (StB). 

[0033] As mentioned before, there are various well- 
known authentication protocols that may be used for the 
onerway authentication flows above, as well as in the ■ - 
scenarios below. In step 3, T could run a two-way au--. 
thentication protocol. This would foil an attacker mas- 
querading as the server S. In scenarios where the user 
U has to authenticate to the server S, step 4 can also 
be carried out in form of a mutual authentication ex- 
change, renouncing steps. 7 and 8. As long as the user 
U is not identified to T or the sen/er S, the itinerary of . 
the user U is kept confidential from T. 
[0034] The scheme described above can- be summa^; 
rized as foltows. The personal device 2 is equipped with t - 
means such that it can be coupled to the terminal 6. It 
furthermore comprises code which, when being execut- • 
ed in the device 2, performs a method for establishing- . 
a trustworthy connection between the user 1 and the ter- . 
minal 6. This terminal 6 is connected to and authenticat- '■■ 
able by at least one server 5 which is authenttcatable by 
the device 2. If the device .2 is coupled to the iermina) . 
6, which coupling may be performed by physical, optical ^ ^' 
or wire-bound or wireless rheans,' the following steps are - 
carried out].- • . ; ■ ... 

'A first authentication step Al Is initiated during wrtiich sf?' 
the terminal. 6 authenticatss itself to the server 5: " 
Upon success of this initiation, a first authenticated ' 
^trusted connection cl is establisiied between, the - . 
server 5 and the. terminal 6. ■ : 

• Then, a second authentk^at ion step All is initiated 
during which - via the established first authenticated . 
trusted connection cl - the server 5 authenticates 
itself to the 'device 2. Upc»i success of this. authen- 
tication, a second authenticated trusted connect kxi 
c2 is established between the server 5 and the de- 
vice 2.--t' . • : .. .^^ • ■ = . ' f '■. 

• Thert, a terminal authenticity message (mj) is re- 
ceived by the device 2 during a first messaging step : 
Mf.. This message is received from the server 5 via ■ . 
the established second authenticated trusted con- 
nection c2 and confirms the established authenticity 
of therterminal 6. : . . 

• Then, during a secorxi messaging step MM, an au- . 
th ent icfty outp ut message (mo) is p rovide by the de- 
vice 2 to the user;1. This is done via an output of 
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the device 2 and/or via a terminal output 3 of the 
terminal 6. ' 

[0035] The personal device 2 nnight comprise stored 
predetermined authentication information (vec) which s 
can be sent to the terminal 6 for it to create the authen- 
ticity output message (m^). The preferred case might be 
that the authenticity output message (mj is sent by the 
server 5 to the terminal 6. This authenticity output mes- 
sage (m^) might comprise visible, audible, or tactile in- io 
fornnation, e.g.. one or more of the following: back- 
ground color, foreground color, background pattern, 
sound, letters, numbers. Likewise, the authenticity out- 
put message (m^) might comprise at least one value for 
lookup in a table which Is stored In the terminal 6, for 15 
example. The authenticity output message (mo) might 
also have been transmitted by the user 1 to the server 
5. This is preferably done via a trusted communication 
connection cs. The authentication steps Al. All, and AMI 
might be bidirectional. ■ 20 

[0036] In the above scenario the terminal 6 is able to 
authenticate itself to the server 5 during the first authen- 
tication step At such that upon success the first authen- 
ticated, trusted connection c1 is established between 
server 5 and the terminal 6. Furthernrwrei the terminal 25 
6 facilitates the establishment of the second authenti- 
cated trusted connection c2 between the server 5 and 
the device 2, For. certain implementations the terminal 
6 might need a terminal output 3. 

[0037] Furtherrnoire, the terminal 6 might comprise a 30 
stored kxjkup table which Is accessible via the authen- 
ticity output message (m(^): 

[0038] Th© server Sfe connected to the terrhinal 6 via 
the network 4 or a link and is able to authenticate the 
terminal 6 during the first authentication step Al. After ss 
the first authentication step Al a first authenticated trust- 
ed connectksiT cl is. established between the server 5 
and the terminal 6. The server 5 is furthermore enabled 
to authenticate itself to the devk;e 2 dijring the' second 
authentication step' All such that. the second authenti- 40 
cated trusted connection c2 is established. Then, the 
server 5 sends the. terminal authenticity' message (m,) 
to the device 2 via the established secOTid authenticated 
trusted connection. c2, to confirm the established au- 
thenticity of the terminals.- ' I . 45 

Case 2: Personal smartcard without output ' 
capabflity ^ - o - v ^ ; ; . • : ,, . 

[0039] Now a scenario is considered where ^ user ^ so 
1 is equipped with the device 2, such as an integrated-- 
circuit card (e.g. a smartcard), which has no output ca- " " 
pabitity. One couW try to use the same solution for this > 
scenario as well. However, the' problem arises In step 6 ' 
since the device D does not have its own display. Con- ss 
sequently, it does not have a trusted path to the user U. 
Th ere may be devices with other types of trusted piaths, 
-e.g., mobile phones coukJ use a speech synthesizer to 



communicatethe message to the user U in which case 
the above described solution could still be used. Stand- 
ard smartcards, however, have no such output mecha- 
nism. Hence one needs to modify the solution. 
[0040] Customizing security -critical windows is a welt- 
known security measure against Trojan horse attacks. 
There have been various proposals. One is described 
by N. Asokan et al. in " Preliminary report on basic serv- 
ices, architecture and design". Technical report, SEM- 
PER Consortium, 1 996. This Technrcal report is a SEM- 
PER Project deliverable which was submitted to the Eu- 
ropean Commission; See http://www.semper.org for re- 
lated information. Another proposal was pubslied by J. 
D. Tygar and A. Whitten in "WWW electronic commerce 
and Java Trojan horses" in Second USENIX Workshop 
on Electronic Commerce, pages 243-250, Oakland, 
California, November 1996. Some variants have also 
been implemented, for example in the SEMPER Trusted 
INteractive Graphical User I Nterf ace (see www. semper, 
org); or the hieroglyphs in the login diatog-t)6x of the Lo- 
tus Notes software: While it is an effective couhtenmeas- 
ure against isimple-minded Trojan horses, it is ineffective 
in a scenario where the Trojan horse has read and write 
access to the display. As soon as a personalized window 
is displayed to the user, the Trojan horse program can 
read the personalization information, construct a fake 
windovir with the same information on top of the legiti- 
mate personalized window. ^ ' - 
[0041] Hereinafter the personalizatkni' idea is com- 
bined wrth authentication protocols to achieve ah effec- 
tive solutkx) for the scenario currently under considera- 
tion. In the current threat model, legal ternmnals are 
tamper-resistant while illegal terminals will not be able' 
to authenticate themselves to the server 5. By not re^ 
vealing the personalization inf6rmatk)n before the ter- 
minal 6 has been authenticated, one can be safe even 
from sophisticated attacker programs. Herein, the 
stronger threat model is considered in whfch an attacker 
may subvert legal terrnirials by, for example, installing 
Trojan horses. ' ■ 
[0042] It is assumed that the user 1 has a trusted 
(home) base (such as a home PC) where he can pre- 
pare his device 2, e.g. a smartcard, before beginning his 
travel. For the preparation, the user 1 iselects a prede- 
termined authentication information vec, also called au- 
thentication vector The authentication vector consists 
here of one or more types of aiithehticatorsr^An authen- 
ticator of a particular type is such that 

• it can take one of several values, 

• each different value can be perceived by an unaided 
human and distinguished from other values: 
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Examples of types of authenticators are: 
[0043] 

• arbitrary text phrase s 

• background colour (of the order 256 possible val- 
ues) 

• foreground colour (of the order 256 possible values) to 

• background pattern (of the order 16 different pat- 
terns) j. _ ^ . ■ ■ 

• sound sequence (of.the order of 256 different tunes) is 

[0044] Another example is to include text phrases that - 
can be pas ity recognized tjyjhe user 1. A variety of- 
means coukJ be employed in order to. show the words . 
to the user 1: e.g., visual - by printing them on a screen . 
-, aural. - by using a speech synthesizer-, or tactile^ - by 
representing the words in braille-. Words and phrases 
constitute the most powerful type of authentrcators since . 
they can be drawn from a relatively large space, and 
they can be communicated to the user 1 in a variety of. . 25 
ways. 

[0045] The steps performed for authenticating the un- 
trusted terminal 6 to the user 1 are depicted in figure 3. ; 
[0046} The trusted heme base here constitutes the, . 
trusted path cO (St1 a) between the device 2 and the user 30 
1. The user,1 hence itrusts, his device 2. To prepare for . , . i 
his travel, the user^l performs a preparation. step P I in 
that he picks, one combination as the predetermined au- . 
thentication information-vec: for .example, a tuple of the 
form phrase = abracadabra, background-color = blye/ 3S 
foreground-color = white, background-pattern - grid. : 
tune = jingle-bells on his trusted home base and stores , . 
it on the smartcard 2 (Sti b). : . , . . 
[0047] When the user-1 walks up.to the untrusted ter- . 
minat 6 and inserts his smartcard 1 into the terminal's : -«> 
reader (St 1c, Stid), the following message flows take 
place: ^ _ x- ^ < . ,■ ■ ■ ; ■ r . i . - . ^ : — > • ■ . 

1 U -> T; I n th 9 first auth entication step A I , the pser - 
U requests T to authenticate itself to the server S, 
e.g., by typing in tfie :identifier of the server S and . 
clicking on a buttm on T's display (Sti e). n : 

2. T -> S: The terminal T runs a one-way authenti- 
cation protocol to tfie server S (St2a).- If this sue- 50 
ceeds, the server S knows that it has an authenti- 
cated channel S-T to T This authenticated channel 
S-T is established as the first authenticated trusted 
connection c1 (St2b). The server 5 hence trusts the 
terminal 6. 

Then a second authentication step A M is per- 
formed making use of the first authenticated trusted 
connect Kin c1. 



3. S -> D: The sender S runs a one-way authentica- 
tion protocol to the device D via the authenticated 
channel S-T (StSa). If this succeeds, the device D 
knows that it has an authenticated channel S-D to 
the server S which is tunneled through the authen- 
ticated channel S-T. This authenticated channel S- 
D is established as a second authenticated trusted 
connection c2 (St3b); 

As next step a first messaging step M 1 follows. 
The terminal sends a session key 'key' to the server 
5(St3c). 

4. S D: The server S sends a message to the 
effect "T is authentic' via S-D. This message is the 
terminal authenticity message m, which. arrives at 
the device 2 via the terminal 6 (St4a). In addition, 
the sen/er S here sends additional information, 
such as the session key 'key', or one-time certifi- 
cates, that are used by the device D and T for a third 
authetication step A Ml. In this step, an authentica- 
tion protocol is run between the device D and T 
(St4b) and upon success of the authenticaticffi a se- 
cure channel D-T is constructed between them- 
selves. This authenticated channel D-T is estab- 
lished as a third authenticated trusted connection . " 
c3(St4c). 

5. D T: Next tol tows the second messaging step 
M 11 during which the device D transmits a message 
to the effect "T is authentk: according. to S' to the 
user U. Since the device D has no own displaiy it 
takes advantage of the display of the terminal 6. The 
devbe D reveals the. pre-selected authentication - 
vector, respectivefy the predetermined authentica- \ 

■.-^ tion inforrriation.vec to the teninina!:T (S15).. . 

6. T -> U:T shows the received authentication vec- 
tor to. the user U, : respectively display^ the prede- 
tenmined authentication information vec or part of it 
on its terminal output, device 3, e.g. by displaying 
the selected colou.'S and background pattern, and ^ 
playing the selected tune. This output informatton 
constitutes .the authenticity output message jr\^. 
The appearing authenticity output message mo tells 

- the user U that he can trust the terminal 6. 

[0048] In other words, the devbe D reveals Ihe au- 
thenticator to T only after the server S has certified that 
T is a legal temninal 6. The probability of an illegal ter- 
minal correctly guessing the authentlcator of the user 1 ' 
Is very small, e.g., of.the order of one in 256 x 256 x 16 
X 256 with the parameters suggested above. If a rogue 
terminal incorrectly guesses the authenticators of sev- 
eral users in ck>se succession, it may be reported to re- ■■ 
sponsible control authorities and thus be detected as an 
illegal terminal. . 

[0049] So far the user U is not identified to T or the 
server S. This helps to keep the ttinerary of the user U 
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confidential from T. 

[0050} The following variations are possible: 
[0051] Smartcards may not have sufficient memory to 
store an authenticator in its entirety. However, it the 
types of authenticators are pre-defined, the smartcard 
needs to store only an index and the terminal 6 can use 
the index to look up the authenticator in a table of all 
possible values for the different components. 

Case 3: Non-writable personal smartcard without 
output capability ' 

[0052] Some smartcards may not be writable by the 
user 1 . In this case, the scheme is modified as shown 
in figure 4: 

1 . During the preparation phase P I, the user 1 se- 
lects the authentication vector and communicates 
It to the server 5 via a confidential, authenticated ■ 
channel cS from his home base. As the authenticia- 
tion vector, respectively as the predetennined au- 
thentication information vec, the user 1 picks one 
combination: for example, a tuple of the form phrase ' 
- abracadabra, background-cotor = blue, fore- 
ground-color - white, background-pattern = grid, 
tune = //ngrfe-f>0/fe. Furthermore, still the trusted 
path cO (Stia) bieftween the device 2 and the user 1 ' 
exists. The user 1 hence trusts his device 2. When 
the usef 1 walks up to the untrusted terminal 6 and ' 
inserts his smartcard 1 into the terminal's reader 
(^1 b,' Sti c), Vne ifotlowihg nnessage flows take 
place: , ' ' ■ ' ' " .j .. ' 

2. D -> f: In the first autfieirttication step A I, the de- 
vice p i-ectueste T tp authenticate itself to th^ server 
S (St2). This request is automatically induced by the 
ihsbhiori of the device b. 

3. T -> S: Jhe terrpinal f runs a one-way alithenti- ' 
datlon protocbi to the server S (St3a). If this suc- 
ceeds, the server S knows that it has an authenti- 
cated channel S-T to T. This authenticated channel ' 
S-T is establishGHd as the first authenticated trusted 
conriectioh c1 (St 3b): The server i5 hence trusts the ' 
termirial 6. ' ' ' . . 

Jhen a second authentication step A 11. .is per- 
formed making use of the ffrit authenticated trusted 
connectiori c1 . *■ ' ■ ^ > • ' 

4. S -4 b: The server S runs a one-way authentica=^* 
tidn protocol to the device D via the authenticated 
channel S7T (St4a). If this succeeds, the devicb D' 
knows that it has an authenticated channel S-D to ' 
the server S which is tunneled through the authem- 
ticated channel S-T. Jhis'authenticated cftanrieil S- ' 
D is established as a second authenticated trusted 
connection b2 (St4b). ' 

As next step a first mesisaging step M I foltows^ ' 
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The terminal sends a session key 'key' to the server 
5 (St4c). 

5. S -> D: The server S sends a message to the 
5 effect 'T is authentic' via S-D. This message is the 

terminal authenticity message m, which arrives at 
the device 2 via the terminal 6 (StSa). In addition, 
the server S here sends additional information, 
isuch as the session key 'key', or one-time certifi- 

10 cates, that are used by the device D and T for a third 
authetication step A III In this step, an authentica- 
tion protocol is run between the device D and T 
(StSb) and upon success of the authentication a se- 
cure chartnel D-T is constructed between them- 

15 selves. This authenticated channel D-T is estab- 
lished as a third authenticaited trusted connection 
c3 {St5c). " 

6. S -» T: Next follows the second messaging step 
20 M tl during which the server S transmits a message 

to the effect "T Is authentic according to S" to the 
user U. Since the device D has no own display, the 
I server S takes advantage of the display of the tbr- 
minal 6; Ttie device D reveals the pre-selected au- 
25 ' thentication vector respectively the predetermined 
"authentication information vec to the tenninal T 
(St6).';This output information canstitutes the au^ 
thenticity output message ftiQ. 

30 7. T-* U: Tshowstherefceivedautheriticity oulput 
' message mi, to the usisr U, respectively displays the 

authenticity output message nr((, or part of it orr its 
terminal output device 3. e.g; by displaying the se- 
lected colours and backgiround pattern, and playing 

35 the selected tune. The appearing authentteity out- 
put message mo tells the user U that he can trust 
the terminal 6. 

[OOSiS] The authentication step in step '5 ts here nec- 
40 essary because the sender S must not reveal the au- 
thentication vector to an attacker who is using a legal 
termirial 6 but pretends to be the Itser 1 , The same aii- 
theriticatiori vector cou Id be used several tinfies. Th e us- 
er 1 could also select a set of iauthenttcation vectors dur- 
'45 ' ing the preparation phase P I . Another variation is where 
the us'er 1 challenges the terminal T to show a different 
component of the authenticatioh vector each time. This 
will also help foil an attacker who vetches of a legitimate 
user 1 and leams his authentication vector 
50 [0054] As in the' previous examples, tlie terrhinal T 
could run a two-way authentication protocol with the 
server S (Step 2). This would foil an attacker masquer- 
ading as the server S.^' " , 

55 Case 4: No personal device 

[0055] Smartcards and other personal trusted devic- 
es may become commonplace in the near future. But to 
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date, their use is still limited. Most users are armed only 
with simple pass-phrases (e.g., in the case of Internet 
access) or memory cards (e.g., in the case of credit/deb- 
it cards). In this section, the scenario is investigated in 
which the user 1 has no personal computing device 2 at 5 
all. The corresponding steps are depicted schematically 
in figure 5. 

[0056] A solution for one way authentication called S/ 
Key, is described by N. Haller in "The S/Key one-time 
password system", Symposium on Network and Distrib- io 
uted Systems Security, Catamaran Hotel, San Diego, 
California, February 1994. Internet Society this docu- 
ment is incorporated in its entirety. . , 
[0057] Using such an the S/Key system, a server is- 
sues, a number of challenge/response pairs to a user is 
during an initialisation stage. The user prints out the list 
of these pairs. The responses are essentially one-time 
passwords. In order to access the system, the user iden- 
tifies himself and the server sends a challenge. The user 
then looks up the appropriate response from his printed 20 
list, sends it back to the server, and strikes off that pair 
from his list. It; is proposed to use an S/Key-iike system 
in both directions. 

[00S8] , Before beginning his travel,, in the preparation 
step P t. the server S sends a number of challenge/re- 25 
sponse pairs to the user 1 yia a confident iai^ authenti- 
cated channel. cO to the user's home base and, the user 
1 selects a different authentication vector for each chal- 
lenge and sends the authentication vector / challenge 
pairs back to the server 8. The user 1 also, prints out the 30 
entire list of , <challenge,cesp)onse, authentication vec- 
tor> triples. . . . ' 

£0059] , yVhen the user 1 walks up to an unt rusted ter- 
minal 6, the foltawing message flows take olace: 

1. U -T* T: In the first autheritication step A I, the 
user U requests the terminal f to autheriticate itself 
to the server S, e.g., by typing In the identifiers of 
the user U and the terminal T, and clicking a buttcwi - 
(Sti). ' : ; ' ". ■ ■ ' 'ff^ 

2. T --* 8: the terminal t runs a one-way authenti- .J 
cafllon protocol to the server S. If this succeeds, the/ 
servers knows that it has an authenticated channel 
S-t to the.terminal T. . , 45 

. This authenticated, channel S-T is established 
as , the. first authenticated trusted, connection c1, 
(St2b). the server 5 hence trusts the tenmirial 6. 

Then a second authentication step A II is per-, 
formed making use of the first authenticajted trusted so 
connection c1. , , :, V 

3. S -> T: the server S sends one of the challenges, . 
previously exchanged with the user U during the 
preparation phase P I, via S-T to the terminal T ss 
(St3). ' . • - 

4. T ^ U: The terminal T displays the challenge to 



the user U (St4). 

5. U -> T: The user U looks up the response corre- 
sponding to the challenge on his printout arid types 
it in, provided it is not already struck off (St5). 

6. T -> S: The terminal T sends the response yia S- 
T to the server S (St6). 

7. S -> T: If the response is valid, the server S looks 
up the authentication vector corresponding to the . 
challenge, and sends it via S-T to the tenrtinal T 
,(St7). 

8. T -> U; The terminal T shows the received au- 
thentication vector to the user U (St8). 

[0060] The user U can verify if this is indeed the au- 
thentication vector corresponding to the challenge,. ac- 
cording to.hts printed sheet. If so, he can.be confident 
that the terminal T is a legal terminal 6. the user U then 
strikes off the entry corresponding to the challenge from 
his printed list. If the authehticattori fails, the usetr U as 
well as the server S should still cr'c^s out the entry cor- 
responding to that challenge and never use it again. As 
before the terminal T could ruri a twO:way authentication 
protocol with the server S (step 2). thjs "woukJ foil an 
attacker masquerading as the server S. . 
[0061] Variations of this scheme are addressed be- 
Ipw- „ ; , ' ... 

[0062] The user 1 may vrant to avoid, carrying around 
a printed list. It can also be a security weakness:. if the 
attacker manages to get hold of the printed list, he can 
fool the user; 1 and/qr the server 5. In . this case, he can 
nnake do with a single, authenticatiop vector., Steps 3-6 
are theri dropped. In step 7, the server S sends the au- 
thentication vector to the teiTn|nal T without any further 
checks. This simplification is not secure against target- 
ed attacks wrtiere the attacker obtains the authenticatron 
vectors of specific users, e.g,,^by interaictipg with a legal 
terrninal, sets up a fatke terminal 6, and waits for these 
users to come in. But it . is us^eful against untargeted at- 
tacks, i.e., settiiig up a fake tenminal 6 without specific 
users in rnind. If users change their authentrcaticwi vec- 
;tors regularly, large-scale targeted attacks are not fea- 
sible, . . - ' 

[0063] The authenticity message cian in principle also 
have been transmitted to the user by the^server. , 
[0064] A second variation is, as in the previous sce- 
^narip, the user 1 can be allowed to challenge the termi- 
nal T to show a different componerit of the.^authentba- 
tion ^vector, each tirne: i.e., the user i specifies the type 
of the authentication vector as the challenge since it may 
help the user 1 remember the challenges.. For example, 
it is easier for a user 1 to remember a cotor, a tune^ and 
a word rather.than to remember three colors. . 
[0065] A user 1 need not necessarily remember his 
entire authentkiatron vector, but need only be able to 
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recognrze incorrect authentication vectors. One possi- 
bility to construct authentication vectors with high entro- 
py is to arrange them by themes. For example, the user 
1 could issue a challenge on the theme "car,* and ask 
for specific attributes of his car. A car has several at- s 
tributes which are easy to recognize. 

The approach can be summarized as follows: 

[0066] 10 

(a) a first authentication step Ai is executed during 
which the terminal 8 authenticates Itself to the serv- 
er 5. Upon success of the first authentication, a first 
authenticated trusted connection c1 is established '5 
between the server 5 and the terminal 6. . 

(b) during a second authentication step All a chal- ^ 
lenge is received from the server 5 and output to 
the user 1. . - zo 

(c) Then, a response is received from the user 1 and 
transmitted to the server 5. During a first messaging 
step M I an authenticity output message (mj is re- 
ceived at the terminal 6. . , 25 

(d) During a second messaging step Mil the authen- 
ticity output message (mj is communicated at least 
partially to the user 1 via an output 3 of the temiinal 

6. .' - r 30 

[0067] The above-described approaches depend on 
the level of computational resources availabte.to the us- 
er. In most cases untrusted terminals can be authenti- 
cated and secure session established between the user 35 
and sorne remote server system. for the exchange and/ 
or processing of sensitive infonmation.' 
[00681 = Those skilled in the art will recognize that many 
modifications and changes can be made to the particu- 
lar embodiments ^ described above .without departing 40 
from the spirit and scope of the invention. 
[0069] All the described and depicted .embodiments 
can be combined in total or in part. 

Claims , ; -:, - o.. ;• r 

■ • ■■ ■ " ■ > ■ ■■■ ^' ■ ') ■ 
1. Personal device <2) to be connected to a terminal 
(6) and being equipped with a computerized method 
for establishing a trustworthy connection: between so 
a user (1) via the device (2) and the terminal (6) 
which is connected to and authenticatable by at 
least one server (5) which is authenticatable by the 
device (2). whereby in the case the device (2) is 
coupled to the terminal (6), ss 

: a first authentication, step (A t) is Initiatable dur- 
ing which the terminal (6) authenticates itself to 



the server. (5), upon success of which, between 
the server (5) and the terminal (6), a first au- 
thenticated trusted connection (c1) is estab- 
lished, and 

subsequently a second authentication step (A 
II) is initiatable during which via the established 
first authenticated trusted connection (c1 ) the 
server (5) authenticates ttsetf to the device (2), 
> upon success of which, between the server (5) 
. and the device (2), a second authenticated 
trusted connection (c2) is established, and 

subsequently at the device (2) during a first 
messagirig step (Ml), from the server (5) via 
the established second authenticated trusted 
' connection (c2), a terminal authenticity mes- 
sage (mt) is receivable (confirming the estab- 
lished authenticity of the terminal (6), 

and subsequently during a second messaging 
step (M II) an authenticity output message (nio) 
is communicatable from the device (2) to the 
user (1) via a. device output of the device (2) 
and/or via a terminal output (3) of the terminal 
(6). 

2. Personal device, according to claim 1 , character- 
ized in that It comprises stored predetermined au- 
thentication information (vec) communicatable to 
the terminal (6) for the terminal (6) to create the au- 
thenticity output rhessage {m^^). 

3. Personal device, according to claim 1 or 2, charac- 
terized in that it is able to authenticate itself to the 
terminal (6) during a third authentication step (A 111). 

4. Personal device, according to one of claims 1 to 3, 
characterized in that the initiatable authenticatbn 
steps. (A l-l 11). are bidirectional. 

5. Personal device; according to one of claims 1 to 4, 
characterized in that it is able to request the user 
(1 ) to authenticate himself and that it is able to re- 
ceive user input (PIN) for user authentication. 

6. Personal device, according to one of claims 1 to 5, 
characterized in that the authenticity output mes- 
sage (m<>) comprises visible and/or audible and/6r 

• tactile information, e.g. one or more of the fol towing: 
background color; foreground cb tor, background 
pattern, sound, letters, numbers. 

7. Personal device, according to one of claims 1 to 6, 
characterized in thiat the authenticity output mes- 
sage (m^) comprises at least one value for lookup 
in a table stored in the terrhinal (6)^ • 
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8. Personal device, according to one o1 'claims 1 to 7, 
characterized in that the authenticity output nnes- 
sage (rrio) is communicatable to the terminal (6) by 
the server (5), the authenticity output message (mo) 
preferably having been transmitted to the server (5) s 
by the user (1), preferably via a trusted communi- 
cation connection (cs). 

9. Personal device, according to one of claims 1 to 8, 
characterized in that the authenticity output mes- io 
sage (m^) is communicatable to the terminal (6) by 

the server (5) upon successful authentication of the 
device (2) to the server (5). 

10. Personal device, according to one of claims 1 to 9, t5 
characterized in that the authenticity output, mes- 
sage (mo) is outputable only partially by the terminal 

(6), preferably according to a preselection from the 
user (1). • 

20 

1 1 . Terminal being enabled to be coupled to a personal 
device (2) and being equipped for establishing a 
trustworthy connection to a user (1) via the device 
(2), the terminal (6) being connected to and authen- 
ticatable by a server (5), the device (2) being able 25 
to authenticate the server (5), wherein In the case 
the device (2) Is brought into contact with the termi- 
nal (6), : : . , ) : !- . - 

the terminal (6) Is able to authenticate. itself to so 
the. server (5) during a first authentication step 
(A 1), whereby upon success between the serv- 
er (5) and the terminal (6) a first authenticated 
, r trusted connection (c1) is established, . ■ , - 

whereby upon the server (&) having authenti- 
cated itself successfully to the device (2) during 
a second authentication step (A II) via the es- 
. tablished first authenticated trusted cc»inection 
(c1 ), leading to the establishment, between the 40 
server (5) and the device (2), of a secwid au- 
thenticated trusted connection (c2) and upon - 'f 

thei device (2) having received from the: server 
(5) a terminal authenticity message (m^, via the 4S 
established second authenticated trusted con- 
nection : (c2), confinning the established au- 
; thenticity Of the terminal (6), 

, it is effected that by the device (2) to the user so 
, (1 ) an authenticity output message (mo) is com- 
municatable via a device output of the device 
(2) and/or via a temninal output (3) of the termi- 
nal (6). ^ ; 

; ■■ 55 

12. Terminal, according to claim 11, characterized in 
that the first authentication step (A I) is eff actable 
by an action of the user (1). 



13. Tennlnal, according to claim 11 or 12. characterized 
in that from the terminal (6) after the first authenti- 
cation step (A I) a session key (key) is issuable and 
communicatable to the device (2) via the server (5). 

14. Terminal, according to one of claims 11 to 13, char- 
acterized in that it comprises a stored lookup table 
which is accessible via the authenticity output mes- 
sage (mo). 

15. Terminal, according to one of claims 11 to 14, char- 
acterized in that the authenticity output message 
(mp) is receivable from the server (5), the authen- 
ticity output message (m^) preferably having been 
transmitted to the server (5) by the user (1), prefer- 
ably via a trusted communication connection (cs). 

16. Terminal, according to one of claims 11 to 15, char- 
acterized in that the authenticity output message 
(mo) is receivable from the server (5) upon success- 
ful authentication of the device (2) to the sender (5). 

17. Temninal, accordtrig to one of claims 11 to 16, char- 
acterized in that it is able to output the authenticity 
output message (mo) only partially, according to a 
preselection from the user (1). 

18. Server connected to a terminal (6) which is enabled 
to be coupled to a personal device (2), being 
equipped for establishing a trustworthy connection 
between a user (1) and the terminal (6) via the de- 
vice (2), and being authenticable by the device (2), 
wherein in the'case the device (2) is coupled to the 
terminal (6); - o - ■ ■ ' ■ ; ■ :■ 

. the server (5) is able to authenticate the termi- * 
nal (6) during a first authenticat'iorH step (A1), 
whereby upon success; between the server (5) 
- ; and the terminal (6); a first authenticated t ru sl- 
iced connection (c1) is established, ' 

the server: (5) ^is furtherrnore iabte to aiithenti-" 
cate itself to the device (2) during a second au- 
thentication step (A 11) via the established first 
authenticated trusted connection (c1 ), whereby 
upon success, between the server (5) and the 
device (2), a second authenticated trusted con- 
nection (c2) is established and -'■ ■ ' 

the server (5) is f urthemnore able to send a ter- 
r minal authenticity message (m^) t&the device 
.' - (2), via the established second authenticated 
. .. trusted connection {c2), confirming the estab- 
■ lished authenticity of the terminal (6), 

whereby it is effected that by the device (2) to 
'the user (1) an. authenticity output message 
(mo) is communicatiable via a device output of 
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the device (2) and/or via a terminal output (3) 
of the terminal (6). 

19. Server, according to claim 18, characterized in that 
from the terminal (6) after the first authentication 
step (A I) a session key (key) is receivable and com- 
municatable to the device (2). 

20. Server, according to claim 18 or 19, characterized 
in that the authenticity output message (m^,) is send- 
able to the terminal (6), the authenticity output mes- 
sage (m^) preferably havihg been transmitted to the 
server (5) by the user (1 ), preferably via a trusted 
corn munication connection (cs). 

21. Server, according to one of claims 18 to 20, char- 
acterized in that the authenticity output message 
(m^) is sen dab le to the terminal (6) upon successful 
autrtehtication of the device (2) to the server (5). 

22. Method, executable by a personal device (2), for es- 
tablishing a trustworthy connection between a user 
(1) via the personal device <2) and a terminal (6) 
which is connected to and authenticatable by at 
least one server (5) which is authenticatable by the 
device (2), whereby in the case the device (2) is 
coupled to the terminal (6), ' 

a first authentication step (A I ) is initiated during 
which the temninaf (6) authenticates itself to the 
server (5), upon success of which, between the 
server (5) arid the temninal (6). a first aiittienti- 
cated trusted connectidn (c1) is established, 
' ' and ' ' - ■" ' ■ ; 

subsequently, after a second autHienticatlm 
step (All) during which via the established first 
authenticated trusted cohriectiori (cl ) the'serv- 
er (5) has successfully authenticated itself to 
the device (2), between the server (5) arid the 
device (2), a second authenticated trusted con- 
nection (c2) is established, ahd- 

sirbsequeritty, at the device ^2) during a first 
' messaging step (M \), from the server (5) via 
the established second authenticated trusted 
connection (c2), a terminal^ aiithenticity rhes- 
sage (mt) ' is received confirming" the estab- 
lished authenticity of the terrninal (6), 

[ and subsequently during a second "messaging 
step (M H) an authenticity output message {mj 
is communicated from the device (2) to the user 
(1) via a device output of the device (2) and/or 
via a terminal output (3) of the terminal (6). 

23. Method, accordirig to claim 22, characterized in that 
stored predetermined autheritication information 



(vec) is communicated from the device (2) to the 
terminal (6), for creating there the authenticity out- 
put message (mj. 

5 24. Method, according to claim 22 or 23, characterized 
in that the device (2) authenticates itself to the ter- 
minal (6) during a third authentication step (A Ml). 

25. Method, according to one of claims 22 to 24, char- 
10 acterized in that the device (2) requests the user (1 ) 
to authenticate himself, whereafter the device is 
waiting to receive user input (PIN) for user authen- 
tication. ' 

*5 26. Method, according' to orie of claims 22 to 25, char- 
acterized in that the device (2) outputs the authen- 
ticity otrtput message (m^^) in form' of a visible'and^ 
or audible and/dr tactile information, e.g. one or 
more of the following: background color, foreground 

20 color, background pattern, sound, letters, numbers. 

27. Methid, according to one of . claims 22 to 25, char- 
acterized in that the authenticity output message 
(m^) is communicatable to the terminal (6) by the 

25 server (5) upon successful authentication of the de- 
vice (2) to the server (5); 

28. Method, according to one of claims 22 to 27, chair- 
acterized In that the authenticity output message 
(rhp) is output only partially by the temninal (6). ac- 
cordin gi to a preselection by the user ( 1 ). 



29. Method; Executable by a terminal (6), for establish- 
ing a trustworthy connect iori between a user (1 ) via 
a personal device (2) and the tenninal (6) which is 
connected to and authenticatable by at least one 
server (5) w^i(^ is authenticatable by the device (2), 
wtiereby in the c^sethe device (2) is coupled to the 
terminal (6), \ *• ' ■ ' 



35 



40 



45 
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a first authentication step (A I) is initiated during 
which the terminal (6) authenticates itself to the 
server (5). upcHi success of which, between the 
server (5) and the terminal (6), a first authenti- 
cated trusted conhectiori (c1) is established, 

in preparation di 'a second authentication step 
(A II) during which via the established first au- 
thenticated trusted connection (c1) the server 
■ (5) mray'authenticate itself to the d&vlce (2), and 
lipdn sJccess of this authentication step, be- 
tween the server (5) and the device (2), ia sec- 
ond authenticated trusted conn eel ion (c2) is es- 
tablishable. after which at the device (2) during 
a first messaging step (M I), from the server (5) 
via the established second authenticated trust- 
ed connection (c2), a terminal authenticity mes- 
sage (m^) is receivable confirming the estab- 
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lished authenticity of the terminal (6), and sub- 
sequently during a second messaging step (M 
11) an authenticity output message (m^^) is com- 
municatable from the device (2) to the user (1 ) 
via a device output ot the device (2) and/or via 
a terminal output (3) of the terminal (6). 

30. Method, according to claim 29, characterized in that 
the first authentication step (A I) is effectabte 
through an action of the user (1). 

31. Method, according to claim 29 .or 3p,:Characterized 
in that from the terminal (6) after the first authenti- 
cation step (A I) a session key (key) is issued and 
communicated to the device (2) via the server (5).- 

32. Methpd. according to one of cjaims 29 to 31 , char- 
acterized in that a lookup operation is performed us- 
ing a stored lookup table which is accessible via the 
authenticity output message (m^,). ; 

33. Method, executable by a server (5). for establishing 
a trustworthy connGctton Isetween a user (t) via a 
personal device (2) and a terminal (6) which is con- 
nected to and authenticatable by at least tf>e server 
(5) which is authenticatable by the device (2), 
whereby in the case the device (2) is coupled to the 
terminal (6), - - 

the server (5) authenticates the tenminal (6) 
during a first authenticatbr\step (A l), whereby 
upon success, between the server (5) and the 
- terminal (6), a first authenticated trusted con- 
nectran (c1 ) is established, 

the server (5) authenticates Itself to the device 
. (2) during a second authentbation- step (A 11) 

'■ via the established first authenticated trusted 
connection (ci), whereby upon, succtess be- 
tween the server (5) and the device (2) a sec- 

, ond authenticated trusted connection (c2).is es- 
tablished arid - . . , 

the server (5) sends , a terrninal authenticity 
message (m^;to the device (2), via the estab- 
lished seccHid authenticated trusted connection 
(c2), confirming the established authenticity of 
the terminal (6), - ■ ... . ;.■ - 

whereby, it is effected that, by th^. device <2) to 
^ the user (1) an authenticity output message 
(m^) Is communtcatable via a device output of 
the devbe (2) and/pr via a terminal output (3) 
of the terminal (6), having received a predeter- 
mined authentication Information (vec) stored 
on the device (2). 

34. Method, according to claim 33, characterized in that 



from the terminal (6) after the first authentication 
step (A I) a session key (key) is received and com- 
municated to the device (2). 

5 35. Method, according to claim 33 or 34, characterized 
in that the authenticity output message (m^) is sent 
to the terminal (6), the authenticity output message 
(mj preferably having been transmitted to the serv- 
er (5) by the user (1),. preferably via a trusted com- 

10 rnunication cpnnection (cs). 

36. Method, according to one of claims 33 to 35, char- 
acterized in that the authenticity output message 
(mg) is Is sent to the terminal (6) upon successful 

IS authentication of the device (2) to the server (5). 

37. Method, executable by a terminal (6), for establish- 
ing a trustworthy connection between a user (1 ) and 
the terminal (6) which is connected to and authen- 

20 ticatable by at least one server (5), the user (1 ) and 
the server (5) having, agreed on atteast one infor- 
matlon-tupe! containing a challenge, a response 
and ap authenticity output message (mj, 

25 , whereby a first authentication step (A I) is.exe- 

. cuted during which .the. terminal (6) authenti- 
cates itself to the server (5), upon success of 
which, between the server (5) and the terminal 
(6), a first authenticated trusted connection (c1 ) 

30 Is established, and ; . 

during, a second authenticatipn step (A -I I) the 
, challenge Is receryed from the server (5) and 
output to the user (1 ), and subsequently the re- 
35 .., sponse is received from the user (1 ) and trans- 

mitted to the server (5). and 

during a first nriessaging step (M I) Iram the 
server (5) an authenticity output rnessage (rrio) 
40 , ^is. received at the terrninal (6)i 

and subsequently, during a second messaging 
step (M II) the authenticity output message (rTV>) 
is pomrriunicated at least. partially to, the . user 
~ . ■ (1) yia a terrninal output (3) of the terminal (6). 

38. Method, according to clairn ^7. characterized in that 
the first authentication step (A I) is etfectable by an 
action of the user (1 ). ... , ■ , 

so 

39. Terminal being equipped for establishing a trustwor- 
thy connecticn to a user (1) and being connected to 
and authenticatable by a server (5), 

55 . the user (1) and the server (5) having agreed 

on at least one Information-tupel contatng a 
challenge, a response and an authenticity out- 
put message (m^^), 
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thG terminal (6) being able to authenticate itselt 
to the server (5) during a first authentication 
step (A I) upon success of which, between the 
server (5) and the terminal (6), a first authenti- 
cated trusted connection (c1) is established, 5 
and 

upon reception, during a second authentication 
step (A MX of the challenge from the server (5), 
being able to output the challenge to the user io 
(1), and subsequently to receive the response 
from the user ( 1 ) and to transmit it to the server 

(5) , and 

during a first messaging step (M I) being able is 
to receive from the server (5) at least part of the 
authenticity output message (mg), 

and subsequently during a second messaging 
step (M II) to communicate at least part of the 20 
authenticity output message (rrv)tothe user (1) 
via a terminal output (3) of the terminal (6). 

40. Method, executable by a server (5), for establishing 

a trustworthy connection to a user (1) and being 25 
connected to and able to authenticate a terminal (6), 

the user (1 ) and the server (5) having agreed 
on at least one tup el containing a challenge, a 
response and an authenticity output message so 
(mo), 

whereby a first authentication step (A I) is exe- 
cuted during; which the^ terfninal (6) authenti- - 

Gates itself to the server (5), upon success of 3S' 
which, between the sender (5) and the terrnlnal 

(6) , a first authenticated trusted connection (c1 ) 

is established, and i 

during a second authentication step (A II) the 40 
challenge is sent to the terminal (6) f rem where 
the response is received, and 

during a first messaging step (M I) by the server 
(5) the authenticity output message (m^) is sent 45 
at least partially to the terminal (6), 

and subsequently during a second messaging 
step (M II) at least part of the authenticity output 
message (mj is communicatable to the user 50 
(1 ) via a terminal output of the terminal (6). 

41. Server being equipped for establishing a trustwor- 
thy connection to a user (1 ) and being connected to 
and able to authenticate a terminal (6), 

the user (1 ) and the server (5) having agreed 
on at least one tupel containg a challenge, a 



response and an authenticity output message 
(mo). 

the server (5) being able to authenticate the ter- 
minal (6) during a first authentication step (A I) 
upon success of which, between the server (5) 
and the terminal (6), a first authenticated trust- 
ed connection (c1) is established, and 

being able to send during a second authentica- 
tion step (A II) the challenge to the terminal (6), 
which is able to output the challenge to the user 
(1), and subsequently to receive the response 
from the user (1) and transmit it to the server 
(5), and 

after having received the response, during a 
firs! messaging step (M I) being able to send at 
least part of the authenticity output message 
(mo) to the terminal (6) which subsequently dur- 
ing a second rhessaging step (M II) is able to 
communicate the autheriticity output message 
(m^) to the user (1) via a terminal output (3) of 
the temninal (6). 
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